Since the advent of computers, multiple operating systems (OS) have emerged amongst which Linux/Unix, Windows and MacOs are today's major systems. It was not unexpected that, for a specific user application, the most efficient piece of software would be the privilege of one of these OS. Thus, for a broad range of applications, and to deliver the best software tools available, one needs to have access and to maintain a broad range of operating systems. In addition, to answer the always increasing demands of the users, some applications require greater resources than available on traditional desktop computers, requiring the integration of multi-processors and hardware specific components.
The latter two points have given resistance on both the customers and the IT staffs parts. There are many reasons for this: specific hardware components are expensive and usually need specific programming skills, developing on a multi-computer environment is a challenging task and maintaining multiple OS involves an up-to-date knowledge on every OS changes and security issues.
Over the years, different solutions have emerged to provide both users and IT staffs with improved hardware infrastructures and computer network architectures. However, there are still some major limitations.
A so called thick-client strategy applied to medical imaging network implies that every computationally intensive task associated with generating images, e.g. image rendering, be performed locally on locally stored copies of data obtained from a data server, generally the hospital PACS.
There are two major drawbacks related to such approach: (1) data must be transferred prior to rendering execution, and (2) the client computer must have sufficient processing power to process the desired data. Thus, a user must accommodate his workflow with respect to when the patient data will be locally available, and the same user must make sure to have access to a proper computer at that time in order to review the downloaded patient data. This partially explains why Imaging Rooms are overloaded when multiple radiologists wish to review cases at the same time. As well, on-demand download of any patient data is not recommended has it is time and bandwidth consuming.
A so called thin-client scheme may be viewed as the opposite strategy to the thick client approach. The thin-client architecture comprises a server computer and multiple thin-client computers connected to the network comprising the server computer. The server includes or is attached to an image data storage, for example, a medical image data storage, and integrates the desired software applications and processing capabilities. The thin-client computers, via the network, request a remote control of a specific software application in order to virtually benefit the server computer capabilities in terms of fetching the medical images and further processing them. The computational load is performed at the server location, but is visualized on interacted on at the thin-client location.
The thin-client network may be heavily loaded (low bandwidth network, many simultaneous thin-client connected), but deliver any application at every desired thin-client location. The workflow of the user is thus dramatically improved over the thick client scheme as, while the server is not overloaded, any thin-client can potentially work from anywhere.
Despite its simple concept, the thin-client technology has many variations that attempt to more or less efficiently load the server side, the client side and the available network bandwidth. As well, different schemes are proposed in order to efficiently prevent any computationally intensive tasks to be carried at the client side in order to be independent of the client's hardware and software architecture as well as being independent from the application to be delivered over the network.
An approach between the “pure” thick-client and “pure” thin-client network architectures for image rendering proposes an architecture splitting the rendering tasks in between a server and a client. It is meant for rendering synthetic data, representing 3D geometric models where background and foreground objects can and must be identified prior any rendering, and where foreground objects are rendered at the client side and background objects are rendered at the server side. A composite of both the renderings is then displayed to the user at the client side. Such approach is specifically designed for application involving synthetic images integrating a plurality of different geometric object such as Computer Assisted Design applications or computer games. Two of the limitations of such techniques are: 1) the application delivered from the server to the client must be a-priori known in order to apply the proposed scheme, i.e. such strategy must be integrated directly within the delivered application source code in order to capture foreground and background objects (not applicable for any desired random application), and 2) Such an approach is not applicable in cases where a decomposition into the foreground/background and/of a different geometric object are not applicable, for example in Medical Imaging where the synthetic data are composed of voxels representing continuous and not differentiable human body parts.
A different thin-client solution is where the client to which the application is delivered must provide the appropriate User Interface to use the delivered application. This implies that the client knows a-priori the kind of application that can be delivered and that the client possesses the appropriate kind of interface a desired application would require. As a fallback mechanism, the proposed methodology may deliver such specific User Interface through a Web Browser via a Java based Module. Such requirements may lack in many cases, specifically when considering network and computer security issues that are predominant in Hospital structures, for example.
The two major limitations of such techniques are: 1) the application delivered from the server to the client must be a-priori known in order to apply the proposed scheme, i.e. such multi-node distribution architecture must be integrated directly within the delivered application source code in order to apply the desired buffering strategy (not applicable for any desired random application), and 2) such an approach is not applicable in cases where a client have no a-priori installed User Interface required by a desired delivered application and/or where a client have a restricted or no internet browser Java Enabled (not applicable within secured infrastructure like Hospitals and banks, for example).
Another solution is a web-based approach for delivering a video stream where the server must be specifically adapted for the application delivering process.
Three of the limitations of such techniques are: 1) the application delivered from the server to the client must be a-priori known in order to apply the proposed scheme; 2) such approach is not applicable in cases where a client has no a-priori installed User Interface required by a desired delivered application and/or where a client has a restricted or no Java Enabled Internet browser (not applicable within secured infrastructure like Hospitals and banks, for example); and 3) such strategy does not provide any information and/or embodiment assuring the data integrity in case of multiple/collaborative streaming process (not applicable in collaborative strategies requiring multi-client interactions on a unique stream).
An alternative strategy focuses on medical data visualization, whether for single or collaborative strategies.
There are two major limitations when considering the strategy described in these documents: 1) The client must have the User Interface corresponding to the delivered application locally installed and integrating the delivered application rendering features, i.e. if the abilities of the delivered application in terms of medical data volume rendering are not known and physically not accessible in terms of libraries then the application is not deliverable (not applicable for any desired random application), and 2) According to the following scheme and considering a collaborative strategy where multiple users are working simultaneously on the same delivered application, every User Interfaces at every client side is physically unlinked from each other and must be updated once one of the client has performed an action and transmitted its parameters to the others (no real-time collaborative work).
A strategy for volume rendering application delivery proposes coupling a volume rendering engine with a video streaming engine to further deliver the resulting video stream to a remotely located client.
Two of the limitations of such strategy is that: 1) one needs to have partial or full access to the source code of the desired application integrating the volume rendering engine in order to couple such volume rendering engine with a video streaming engine (not applicable for any random desired application); and 2) no process if presented to maintain the application data integrity in case of multiple collaborative work on an unique application delivered to multiple clients (not applicable for real-time collaborative work on a delivered application).
Tentative solutions to the above mentioned limitations rely on compression of the video information based on its content. Such a-priori cannot be satisfied in medical imaging, for example, where the content of the synthetic images could be as broad as a complete human body with every organs to the observation of a single cell. As well, this is not satisfied in the case of random and/or unknown content (not applicable for any random desired application).
There are no scheme to deliver an unknown application from a server to at least a client (no information required on the application at the server side, no intrusion/modification within the application source code at the server side, operating System independent scheme), without requiring any a-priori information on that application at the client side (no graphical user interface required at the client side to interact with the delivered application), and which seamlessly allows a collaborative and simultaneous work from multiple client having the same application delivered (maintain the integrity of the delivered application data, real-time collaborative work).
As such, there is a need for a method and apparatus to overcome the drawbacks and shortcomings mentioned hereinabove.